Verify the packed worker-bundler at build time - #1798

Problem

The compiled executor binary — the same binary the desktop app ships as its daemon — cannot resolve @cloudflare/worker-bundler by name. bun build --compile puts JS in bunfs, which has no node_modules, so a bare specifier evaluated inside the binary throws Cannot find module '@cloudflare/worker-bundler' at startup. The package is also unembeddable in principle: its payload is a 13.9 MB esbuild.wasm that is read from disk, not imported.

The delivery mechanism for that is colocation: build.ts copies the package's dist/ next to the executable, and native-bindings.ts publishes the absolute path as EXECUTOR_WORKER_BUNDLER_DIR for consumers to load from. That handoff was only half-built.

• The required file list existed in two places, free to drift — and had. The build writes dist/index.bundled.js (the entry consumers load, packed so it has no bare imports of its own), while the runtime check only looked for dist/index.js and dist/esbuild.wasm.
• Nothing verified the staged copy after the compile. build.ts validates its build inputs but made no assertion about the bin/ directory it produced, so a partial staging shipped a binary that was fine on the build machine and broken on the user's.
• The runtime check failed open. When a file was missing it silently skipped setting the env var, leaving any consumer to fall through to the bare specifier and crash on startup. That silent skip is what turns a packaging slip into a crash loop.

For context on scope: the last consumer of this module was removed in #1476, which deliberately kept the packing for when it returns. So this is the delivery contract being made sound before something depends on it again, not a fix for a live import.

Fix

• New apps/cli/src/worker-bundler-artifact.ts holds the required-file list as a single shared contract, plus a pure missingWorkerBundlerFiles(dir, exists) that takes its existence probe as a parameter. The build script and the runtime bootstrap both use it, so they cannot disagree. This also corrects the list to include dist/index.bundled.js.
• build.ts asserts the staged copy after compiling each target: every required file present, a size floor on the packed entry, and the \0asm magic on the wasm so a truncated or pointer-file copy cannot pass as real. A packaging slip is now a red build instead of a broken install. This follows the shape of the existing asset assertions in apps/cloud/scripts/build.mjs and apps/host-selfhost/scripts/assert-shell-asset.mjs.
• native-bindings.ts no longer swallows a bad copy. A directory that is present but incomplete is reported on stderr naming the missing files and telling the user how to repair it — not caught and ignored. A directory that is absent entirely stays quiet, since that is the normal non-packaged path (dev, bun run).

Testing

typecheck, lint (0 warnings, 0 errors) and format are green.

Unit — apps/cli/src/worker-bundler-artifact.test.ts, 6 tests. These are the build-time guard the contract needs: they fail if a required file is dropped from the list, specifically covering the two historical drift cases (wasm staged without the JS entries, and the unbundled index.js staged without index.bundled.js).

Built the real daemon binary and ran it, rather than relying on file paths:

• bun ./scripts/build-sidecar.ts from apps/desktop compiles the CLI binary and stages it — the new post-compile assertion passes against a correct staging.

• bun run test:smoke (smoke-sidecar.ts) drives the compiled binary end to end: daemon ready, 1Password SDK loads, and listPets + getPet round-trip through a live OpenAPI server via MCP to QuickJS.

• Degradation path proven by tampering rather than asserted: with worker-bundler/dist/esbuild.wasm moved aside, the daemon still reaches ready and prints

  executor: the bundled Worker toolchain at <path> is incomplete (missing dist/esbuild.wasm). Features that build Workers will be unavailable; reinstall or update executor to repair it.

  With the file restored, it starts clean with no such message. Before this change the same tampering produced no output at all.

Platform limitation, stated plainly: all of the above was run on macOS arm64, not Windows. Desktop e2e targets were out of scope. This is a fair proxy but not identical coverage: the compile and staging path is genuinely shared — one Bun.build({ compile: { target } }) loop, and the worker-bundler copy is unconditional for every target — so the assertion and the shared contract behave the same everywhere. What macOS cannot exercise is the Windows-specific packaging leg (NSIS extraResources) and, more importantly, that native-bindings.ts anchors on dirname(process.execPath): if a Windows install ever launches a relocated executor.exe, every colocated sibling is lost at once, and this change makes that visible rather than fixing it. A cross-build (BUN_TARGET=bun-windows-x64) compiles but cannot be run or smoke-tested from macOS.